Prepare a website change through GitHub

Select the repository and website

Open Integrations, connect GitHub and select the repository that serves the website. Enter its production URL in the repository selection form. For new article files, also configure the intended article directory.

Check repository access, not just account sign-in. If the repository is absent, use the connection’s repository-access management to authorize it. The source branch matters too: the repository’s default branch may not be the branch used in production.

Request a bounded change

In our selected website repository, update [page URL] with the approved
copy below. Inspect the source that renders this route and identify its
branch. Preserve the layout. Update the title and description where
needed, then show the proposed file changes for review.

Include the replacement text, relevant assets and behavior to preserve. If a page moves, include the old and new addresses so redirects, canonical and sitemap changes can be reviewed together.

A small SEO change you can inspect line by line

The following is a fictional HTML example. Your site may keep metadata in a framework component or a CMS field; Afield must find the actual rendering source rather than create a second file at this sample path.

<!-- Before: the title does not identify the service. -->
<title>Services | Example Components</title>

<!-- Proposed: use this only if the page offers this work. -->
<title>Small-batch CNC machining to your drawings | Example Components</title>
<meta name="description" content="Send your drawing revision, material,
quantity and inspection requirements for a small-batch machining review.">

The review should identify where this title comes from, retain the page's existing canonical URL and explain any other touched file. A title change alone should not replace the layout or alter unrelated pages. If the source already contains a more specific promise, compare both versions against the actual service before accepting the replacement.

Open the pull request and check that the change is limited to the intended route. After your release process publishes it, inspect the public HTML and the visible page. A successful repository request does not establish that a deployment ran or that Google has recrawled the title.

Review the proposal before applying it

Inspect the selected repository, source branch and changed files in the prepared action. Afield reads the source before preparing updates. If that source changed after the proposal was prepared, refresh the proposal against the current version instead of overwriting it blindly.

After you confirm a supported GitHub change, the workflow returns a pull request for review. Check its diff, relevant build results and preview when available. A prepared card is not a committed change; a pull request is not a deployment.

Follow the change to the public page

Use your repository’s normal review, merge and deployment process. Then open the public route independently of the preview. Check the updated passage, links, images and narrow-screen layout. Keep the change reference beside the public result.

For moved pages, use the migration map to inspect the old address and new canonical.